add http.{request,response}.body.content#3521
Conversation
… into http-request-response-body
|
This PR contains changes to area(s) that do not have an active SIG/project and will be auto-closed:
Such changes may be rejected or put on hold until a new SIG/project is established. Please refer to the Semantic Convention Areas |
|
@trask can you re-open this ? Should we create a dedicated SIG/project to handle that ? |
… into http-request-response-body
|
Update: updating to cover request + response (as suggested here) and also making it client+server. |
Co-authored-by: Liudmila Molkova <neskazu@gmail.com>
|
This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days. |
… into http-request-response-body
|
This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days. |
… into http-request-response-body
… into http-request-response-body
|
|
||
| To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. | ||
|
|
||
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. |
There was a problem hiding this comment.
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. | |
| Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it. | |
| > [!WARNING] | |
| > This attribute may contain sensitive information. |
a bit more clarity and also this is a standard incantation we use in semconv to mark sensitive things.
There was a problem hiding this comment.
it seems it was lost since it was applied to md and regenerated from yaml, adding comment to yaml, please make sure to update response body too
Co-authored-by: Liudmila Molkova <neskazu@gmail.com>
… into http-request-response-body
… into http-request-response-body
|
Hi maintainers (@AlexanderWert , @arminru , @kamphaus , @joaopgrassi , @jsuereth , @lmolkova , @trask ), is there anything that's blocking progress on this? Would be really great to get the sem conv merged to unblock implementations. |
lmolkova
left a comment
There was a problem hiding this comment.
A few minor suggestions, looks good otherwise!
| note: | | ||
| Captured value MAY be limited in size and thus value is expected to be truncated in many cases. | ||
|
|
||
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. |
There was a problem hiding this comment.
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. | |
| Instrumentations MUST NOT capture this attribute by default and MAY provide an option to enable it. | |
| > [!WARNING] | |
| > This attribute may contain sensitive information. |
|
|
||
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. | ||
|
|
||
| Instrumentations SHOULD capture the body as string whenever possible as it makes it easier to use in human-readable form, also it allows to implement sanitization if needed. |
There was a problem hiding this comment.
| Instrumentations SHOULD capture the body as string whenever possible as it makes it easier to use in human-readable form, also it allows to implement sanitization if needed. | |
| When instrumentations record body, they SHOULD capture the body as string whenever possible as it makes it easier to use in human-readable form, also it allows to implement sanitization if needed. |
| Instrumentations that implement request body recording MUST NOT intentionally introduce side effects such as changing stream position or closing body stream independently from the | ||
| application. | ||
|
|
||
| When body is recorded on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. |
There was a problem hiding this comment.
nit: we might want to stamp them on logs in the future
| When body is recorded on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. | |
| When body is recorded, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP call has ended. |
|
|
||
| To prevent excessive overhead and storage by default, instrumentations MUST issue a warning when the feature is used without an explicit `AttributeValueLengthLimit` configuration option. | ||
|
|
||
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. |
There was a problem hiding this comment.
it seems it was lost since it was applied to md and regenerated from yaml, adding comment to yaml, please make sure to update response body too
| note: | | ||
| Captured value MAY be limited in size and thus value is expected to be truncated in many cases. | ||
|
|
||
| Instrumentations MUST disable capture by default and provide an opt-in configuration option to enable it as it can capture sensitive information and cause performance overhead. |
| Instrumentations that implement response body recording MUST NOT intentionally introduce side effects such as changing stream position or closing body stream independently from the | ||
| application. | ||
|
|
||
| When body is recorded on HTTP client or server spans, the instrumentation SHOULD record part of the body that was sent or received at the time HTTP span has ended. |
There was a problem hiding this comment.
please sync with suggestion on request body (let's not focus on spans)
Pull request dashboard statusStatus last refreshed: 2026-07-25 21:52:31 UTC.
This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected. If you believe this pull request is incorrectly routed as waiting on the author, comment |
Part of #857
http.{request,response}.body.contentattribute as typeany.Covers both the request and response, however the implementation is likely to focus on the server request first: